Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems. MOM allows application modules to be distributed over heterogeneous platforms and reduces the complexity of developing applications that span multiple operating systems and network protocols. The middleware creates a distributed communications layer that insulates the application developer from the details of the various operating systems and network interfaces. APIs that extend across diverse platforms and networks are typically provided by MOM.
In a publish-subscribe messaging model, subscribers typically receive only a subset of the total messages published. The process of selecting messages for reception and processing is called “filtering.” There are two common forms of filtering: topic-based and content-based. In a topic-based system, messages are published to “topics,” which are named logical channels. Subscribers in a topic-based system will receive all messages published to the topics to which they subscribe, and all subscribers to a topic will receive the same messages. The publisher is responsible for defining the classes of messages to which subscribers can subscribe. In a content-based system, messages are only delivered to a subscriber if the attributes or content of those messages match constraints defined by the subscriber. The subscriber is responsible for classifying the messages. Some systems support a hybrid of the two, i.e., publishers post messages to topics while subscribers register content-based subscriptions to one or more topics. In many publish-subscribe messaging systems, publishers post messages to an intermediary message broker or event bus, and subscribers register subscriptions with that broker, letting the broker perform the filtering. The broker normally performs a store and forward function to route messages from publishers to subscribers. In addition, the broker may prioritize messages in a queue before routing.
Many standardized, as well as proprietary, messaging protocols are currently in use. Consequently, conventional software applications must support multiple protocols to allow communication with different messaging brokers, such as Rabbit MQ, Active MQ, Mosquitto, Solace Appliance, and Solace Virtual Message Router (VMR). This increases the complexity of software applications which use messaging. For example, Message Queue Telemetry Transport (MQTT) is an ISO standard (ISO/IEC PRF 20922) publish-subscribe-based “lightweight” messaging protocol for use on top of Transport Control Protocol/Internet Protocol (TCP/IP). It is designed for connections with remote locations where a small code “footprint” is required or the network bandwidth is limited. The publish-subscribe messaging pattern requires a message broker. The broker is responsible for distributing messages to interested clients based on the topic of a message.
As a further example, the Advanced Message Queuing Protocol (AMQP) is an open standard application-layer protocol for message-oriented middleware. The defining features of AMQP are: message orientation, queuing, routing (including point-to-point and publish-and-subscribe), reliability, and security. AMQP mandates the behavior of the messaging provider and client to allow implementations from different vendors to be interoperable. Previous attempts to standardize middleware have been implemented at the application program interface (API) level (e.g., Java Message Service) and have been focused on standardizing programmer interaction with different middleware implementations, rather than on providing interoperability between multiple implementations. Unlike JMS, which defines an API and a set of behaviors that a messaging implementation must provide, AMQP is a wire-level protocol. A wire-level protocol is a description of the format of the data that is sent across the network as a stream of bytes. Consequently, any tool that can create and interpret messages that conform to this data format can interoperate with any other compliant tool irrespective of implementation language. There are two widely used versions of this protocol, AMQP v0.9.1, and AMQP v1.0.0, each of which has rather different configuration requirements.
Conventional message protocols, e.g., MQTT and AMQP, are standardized and each has a specific behavior, specific models, and specific ways to support messaging. Therefore, a coder must develop software capable of handling one particular protocol, or perhaps more than one, by creating code to implement each desired protocol. Furthermore, specific configuration data must be stored and made accessible for each protocol.